hihi，我是歐娜😺

今天這一條，是大家平常使用 AI 最容易遇到的問題之一：

AI 講錯了怎麼辦？

今天來看 OWASP LLM Top 10 2026 第七名：

LLM07：Misinformation（錯誤資訊 / 誤導資訊）。

看到這裡可能會想：

啊不就是 Hallucination（幻覺）嗎？

有關係，但不完全一樣。

今天真正要看的不是只有：

AI 有沒有講錯？

而是：

AI 講錯之後，有沒有人相信它，甚至真的拿這個錯誤資訊去做事情？

這才是 Misinformation 真正麻煩的地方。

Hallucination 跟 Misinformation 不完全一樣

先把這兩個很容易混在一起的東西拆開。

Hallucination

Hallucination 比較像是在描述：

Model 產生了沒有根據、錯誤或虛構的內容。

例如我問 AI：

幫我找一篇關於 AI Security 的論文。

結果它回答：

Title:
Advanced LLM Security Architecture

Author:
John Smith

Published:
2025 IEEE AI Security Conference

看起來超完整。

有：

作者
年份
Conference
Title

結果你真的去找。

完全沒有這篇🤣

這就是很典型的 Hallucination。

但是如果 AI 幻覺完：

AI 講錯
↓
User 查證
↓
發現不存在
↓
沒有拿去使用

影響可能就停在這裡。

Misinformation 真正開始危險，是當：

AI 講錯
↓
人或系統相信
↓
真的拿去做決策

例如：

AI：這個 Package 可以直接安裝

Developer：好

--> pip install xxx

或：

AI：依照公司規定，這個 Customer 可以退款

Agent：收到

--> 執行退款

這時問題就不再只是：

Model 回答錯了。

而是：

錯誤資訊真的影響了後面的 Decision 或 Action。

所以我自己會這樣記：

• Hallucination → AI 產生錯誤 / 虛構內容
• Misinformation → 錯誤 / 不完整 / 誤導資訊被相信，甚至真的被拿去做事情

Hallucination 可以是 Misinformation 的來源之一。

但 Misinformation 的範圍更大～

AI 最麻煩的地方：它可以很有自信地講錯

如果今天系統直接噴：

ERROR
I DON'T KNOW
NO DATA

其實反而很好處理。

因為 User 一看就知道：

喔，它不知道。

真正麻煩的是：

LLM 很可能在答案不正確的情況下，還是產生一段非常完整、流暢，而且看起來很合理的回答。

例如：

根據公司 2026 年退款政策，購買後 60 天內皆可無條件退款，因此此 Customer 符合退款資格。

語氣超級肯定。

甚至還幫你整理：

Policy
Date
Condition
Conclusion

但如果真正的 Policy 是：

14 天內

那整段話寫得再漂亮都沒有用🤣

這也是 LLM 很容易讓人產生：

Overreliance（過度依賴） 的原因。

因為人很容易把：

講得很順
講得很完整
有條理
有專業名詞

誤認成：

是真的

但：

Fluent ≠ Correct。

講得很像真的，不代表它真的有根據。

Misinformation 不一定是「完全亂講」

還有一個我覺得很容易忽略的地方。

錯誤資訊不一定是：

100% 完全假的東西。

有時候更危險的是：

它大部分都對，只是少了一個很重要的條件。

例如公司規定其實是：

購買 14 天內可以退款

BUT

已啟用某項服務者除外

AI 摘要後變成：

購買 14 天內皆可申請退款。

前半段沒有錯。

但它漏掉了：

已啟用服務者除外

如果客服只看 AI Summary：

Customer 購買第 7 天
↓
符合 14 天規則
↓
退款

但其實 Customer 已經啟用服務。

這時 AI 並不是「憑空捏造」。

它只是：

漏掉了一個關鍵條件。

可是結果一樣可能是錯的。

所以 Misinformation 包含的不只是：

False Information

還可能是：

Incomplete Information
Unsupported Claim
Misleading Summary
Critical Omission

有時候：

少講一件事，跟講錯一件事一樣危險。

RAG 也不能保證答案一定正確

看到這裡可能有人會想：

沒關係，我有做 RAG 啊。

（怎麼又是 RAG，以為 RAG 可以解決一切 XD）

RAG 的確可以降低 Model 完全靠自己亂猜的機率。

概念是：

User Question
↓
Search Knowledge Base
↓
Retrieve Relevant Documents
↓
LLM
↓
Answer

讓 Model 回答之前先拿到相關資料。

但：

RAG ≠ 答案一定正確。

因為中間任何一層都有可能出問題。

例如：

Knowledge Base 本身過期

或：

Retrieve 到錯的 Document

或：

Retrieve 到的資料其實不完整

甚至：

Document 是正確的
↓
LLM 摘要時漏掉關鍵條件

最後一樣可能得到錯誤答案。

例如 Knowledge Base 裡同時存在：

refund-policy-2025.pdf
refund-policy-2026.pdf

現在真正有效的是：

2026 Version

但 RAG Retrieve 到：

2025 Version

LLM 完全按照文件回答。

從 Model 的角度來看：

我有 Grounding 啊。

但答案還是錯🤣

所以做 RAG 時，

除了：

有沒有 Source？

還需要問：

Source 是不是正確的？
是不是最新版本？
是不是完整的？
是不是真的支援這個 Claim？

有來源，也不代表 AI 的解讀一定正確

這裡也很容易有一個錯覺。

假設 AI 回答：

根據 policy.pdf，Customer 可以退款。

下面還真的顯示：

Source: policy.pdf
Page: 12

看起來可信度直接 +100。

但有附上來源真正能證明的應該是：

這份 Source 真的支援 AI 剛剛講的那句話嗎？

而不是：

有顯示 Source，所以一定對。

例如文件真正寫的是：

退款期限為 14 天，
已啟用服務者除外。

結果 AI 回答：

所有 Customer 在 14 天內皆可以退款。

雖然它真的引用了正確文件，

但它對文件的解釋還是錯的。

所以：

有標示來源 ≠ 回答內容真的符合來源

真正重要的是：

Groundedness

可以先把它理解成：

AI 的回答，有沒有真的建立在提供給它的資料上，而不是自己多講、講錯，或漏掉重要條件。

所以我們不能只看：

有沒有 Source？

還要繼續確認：

• 這個 Source 真的有寫這件事嗎？
• AI 有沒有正確理解？
• 有沒有漏掉重要條件？

簡單來說：

來源只是證據的入口，AI 的回答有沒有真的符合來源內容，才是重點。

Agent 出現之後，Misinformation 會更危險

如果只是 Chatbot：

AI 講錯
↓
人看到
↓
人決定要不要相信

至少中間還有人。

但到了 Agent：

AI 判斷
↓
直接執行 Action

問題就不一樣了。

假設今天有一個 Customer Service Agent。

流程是：

Customer Request
↓
Agent 查看 Policy
↓
Agent 判斷是否符合退款資格
↓
Refund Tool
↓
退款

如果 Agent 誤讀 Policy：

實際：
Customer 不符合退款資格

Agent：
符合退款資格

然後下游系統直接相信：

Agent 說可以
↓
Refund Tool
↓
退款完成

這時 Misinformation 已經不只是：

AI 回答錯。

而是：

AI 的錯誤判斷直接變成了一個真實世界的 Action。

這也是 Agentic AI 讓 Misinformation 風險變得更大的地方。

Claim → Check → Act

所以到了會真的執行 Action 的系統，

有一個很好理解的安全概念：

Claim
↓
Check
↓
Act

不要變成：

LLM 說可以退款
↓
直接退款

而是：

LLM：
Customer 符合退款資格

↓

System：
重新 Check

購買日期？
服務是否啟用？
退款狀態？
Policy Version？

↓

條件真的符合

↓

Refund

也就是：

不要把 LLM 的判斷直接當成系統事實。

LLM 可以幫忙：

理解 User Intent
摘要資料
提出判斷

但真正執行高影響 Action 前，

還是應該由 System 去確認：

現在真實的 State 到底是什麼？

這個差別非常重要。

不要讓 AI 自己證明自己是對的🤣

那如果我叫 AI：

請檢查你剛剛的答案是否正確。

可以嗎？

可以當其中一層，但不能把它當成真正的 Verification。

因為流程如果是：

LLM 產生答案
↓
同一個 LLM：
「我剛剛對嗎？」
↓
LLM：
對，我是對的。

……

好像哪裡怪怪的🤣

真正的 Verification 應該盡量依賴：

Authoritative Source
Database
API
System State
Policy Rule
Independent Check

例如：

LLM：
User 的 Subscription 已經取消

不要只問：
你確定嗎？

而是：

System
↓
直接 Query Subscription Database
↓
status = active

那就很明確：

AI 剛剛講錯了。

所以：

Verification 最好去確認真實世界的 Evidence，而不是只確認 Model 對自己的答案有沒有信心。

Confidence 也不代表答案正確

這裡還有一個很容易被誤會的東西：

Confidence。

假設 AI 很肯定地回答：

我有 95% 的信心這個答案是正確的。

看起來很安心。

但從安全角度來說：

Confidence 不是 Evidence。

因為我們真正需要確認的是：

這個 Claim
↓
有沒有可靠 Source 支持？

這個 System State
↓
現在是不是真的如此？

而不是：

AI 有多相信自己？

所以相較於：

Confidence = 95%

更有用的可能是：

Claim:
Customer 已付款

Evidence:
Payment API → PAID

也就是：

用 Evidence 驗證 Claim，而不是只相信 Model 的語氣或 Confidence。

Cross-Agent 又會讓錯誤一路傳下去

現在再把情境放大一點。

假設系統裡不只一個 Agent：

Retrieval Agent
↓
Analysis Agent
↓
Payment Agent

第一個 Agent 負責確認：

User 身分是否驗證完成？

結果 Retrieval Agent 判斷錯了：

Identity Verified = Yes

接著 Analysis Agent 直接相信：

上一個 Agent 說 Verified
↓
那就是 Verified

再傳給 Payment Agent：

可以執行 Payment

最後：

錯誤資訊
↓
Agent A
↓
Agent B
↓
Agent C
↓
真實 Action

這就是很麻煩的：

Cross-Agent Misinformation Propagation。

一開始可能只是：

一個 Agent 判斷錯

但如果每個下游 Agent 都把上游輸出直接當成：

Fact

錯誤就會一路被傳下去。

所以 Agent 之間交換資訊時，

也不能只是：

Agent A 說 X
↓
Agent B 相信 X

有些重要狀態應該重新向真正的 System of Record 確認。

例如：

Payment Status
Identity Status
Permission
Inventory
Subscription Status

這些東西最好問真正管理它的系統。

而不是：

上一隻 AI 說有，那應該就有吧。

🤣

Structured Output 也可以降低「漏掉重要資訊」

前面有提到：

Misinformation 不一定是完全講錯。

有時候是：

漏掉重要資訊。

例如我們叫 AI：

幫我摘要這份 Security Report。

AI 回：

整體系統運作正常，目前沒有重大問題。

但原始 Report 裡其實還有：

Critical Vulnerability: 1
Patch Deadline: Tomorrow

只是 AI 摘要時沒寫進去。

這時候如果只要求：

請摘要這份 Report

Model 自己決定什麼重要、什麼不重要。

就有機會漏掉關鍵內容。

所以對一些比較重要的場景，

可以要求 Structured Output：

{
  "summary": "...",
  "critical_issues": [],
  "deadlines": [],
  "exceptions": [],
  "risks": []
}

也就是：

有些欄位不能讓 AI 自己決定要不要講。

如果：

critical_issues

是必填欄位，

至少可以降低 Summary 完全忽略這類資訊的機率。

那 Misinformation 到底怎麼防？

我自己會整理成幾個方向。

1. 重要答案要有可靠的 Grounding

如果是：

Policy
Price
Account Status
Permission
Inventory
Security State

這種會影響決策的資訊，

不要只靠 Model 自己記得。

應該盡量從：

Database
API
Official Document
Current Policy
Trusted Knowledge Base

取得。

讓 Model：

根據資料回答。

而不是：

憑印象回答。

2. Source 要確認版本與時效性

有 RAG 也要注意：

Source 是否最新？
是否已經過期？
是否來自可信來源？
Retrieve 到的是不是正確文件？

尤其 Policy 很常：

v1
v2
v3

如果舊版文件還留在 Knowledge Base，

就需要避免 Model 把舊規則當成現在的規則。

3. Claim 跟 Evidence 要分開

重要資訊最好能做到：

Claim
↓
Evidence

例如：

Claim:
Customer 已付款

Evidence:
Payment System → PAID

而不是：

AI：
我覺得他應該付過了。

🤣

4. 高影響 Action 執行前重新 Check

例如：

付款
退款
刪除資料
修改權限
發送 Email
執行 Cloud Action

不要：

LLM 說 OK
↓
直接做

而是：

LLM Suggestion
↓
System Validation
↓
Authorization
↓
Action

讓 LLM 負責：

判斷、整理、建議。

System 負責：

確認真實狀態。

5. 重要 Summary 可以使用 Structured Output

如果某些資訊：

Risk
Exception
Deadline
Warning

一定不能漏，

就不要只叫：

幫我摘要。

而是明確要求：

Summary
Risk
Exception
Deadline
Source

都需要輸出。

6. 保留 Human-in-the-loop

尤其是：

Financial
Legal
Security
Healthcare
Critical Operation

這類高影響場景，

不要因為 AI：

講得很完整
看起來很專業
回答速度很快

就直接把最後 Decision 全部交出去。

有些 Action 還是需要：

AI
↓
Human Review
↓
Action

我覺得 Misinformation 最重要的一個觀念

以前我們看到 AI Hallucination，

可能會覺得：

哈哈，它又亂講了。

但當 AI 開始進入真正的 Application，

問題就沒有這麼單純了。

因為 AI 的 Output 可能會變成：

下一個人的 Decision
↓
下一個 Agent 的 Input
↓
Tool Call 的 Parameter
↓
真實世界的 Action

這時候：

AI 講錯

跟：

系統相信 AI 講錯的東西

是兩個完全不同的風險等級。

所以今天我會記：

Misinformation 真正危險的地方，不只是 AI 會講錯，而是錯誤資訊看起來夠可信，最後真的有人或系統照著做。

因此真正要防的也不只是：

怎麼讓 AI 永遠不要 Hallucinate？

因為這件事本身就很難完全保證。

更實際的是：

重要 Claim
↓
找 Evidence

重要 State
↓
重新 Verify

高影響 Action
↓
執行前再 Check

簡單來說：

不要因為 AI 講得很像真的，就把它直接當成真的。

AI 可以幫我們做判斷。

但越重要的事情，

越需要有一個方式回答：

「你說這是真的，那證據呢？」

🤣